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Attorney Docket No. 10559-596001/P21148 
MODEL-BASED LOGIC DESIGN 



TECHNICAL FIELD 

This invention relates to model -based logic design. 

BACKGROUND 

Microprocessor logic design typically includes an 
architectural stage and an implementation stage. 

The architectural stage includes designing a framework of 
functional units that provide performance and functionality of a 
new microprocessor. This framework is typically captured in a 
text-based document. A model of the new microprocessor, 
represented in a high level language such as C++, is generated to 
verify that the function and performance requirements are met. 

The implementation stage involves taking the model and the 
text-based document from the architectural stage and generating a 
Hardware Design Language (HDL) file. 

DESCRIPTION OF DRAWINGS 

FIG. 1 shows a system. 

FIG. 2 shows a graphical model. 

FIG. 3 shows a data structure. 

FIG. 4 shows a logic modeling process. 

DETAILED DESCRIPTION 

Referring to FIG. 1, a system 10 includes a computer 12, 
such as a personal computer (PC) . The computer 12 may be 
connected to a network 14, such as the Internet, that runs TCP/IP 
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(Transmission Control Protocol/Internet Protocol) or another 
suitable protocol. Connections may be via Ethernet, wireless 
link, or telephone line. 

The computer 12 contains a processor 16 and a memory 18. 
5 Memory 18 stores an operating system (0/S) 20 such as 
Windows2 000® or Linux, a TCP/IP protocol stack 22 for 
communicating over network 14, and machine-executable 
instructions 24 executed by processor 16 to perform a logic 
modeling process 100 below. The computer 12 also includes an 
10 input /output (I/O) device 2 6 for display of a graphical user 
interface (GUI) 28 to a user 3 0 and a storage device 32 for 
y3 storing a database 34 . 

; s F The logic modeling process 100 executes in the computer 12. 

i-.* The logic modeling process 10 0 is a process in which a C++ model 

' in! 

rgi5 file and a Hardware Design Language (HDL) file, such as a Verilog 
g (IEEE Standard 1364) file or a Very high speed integrated circuit 

S3 Hardware Design Language (VHDL) (IEEE Standard 1076) file, are 

S generated from a successively refined graphical model. Verilog 

r * is a hardware description language, a textual format for 

20 describing electronic circuits and systems, applied to electronic 
design. Verilog is used for verification through simulation, for 
timing analysis, for test analysis (testability analysis and 
fault grading) and for logic synthesis. 

Referring to FIG. 2, a graphical model 50 is a pictorial 
25 model of a microprocessor design. The graphical model 50 is a 
tool that blends the use of textual description and graphical 
description of logical elements to hierarchically capture a 
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silicon design. The use of graphics is important to "re-use" 
capability and for design support. The graphical model 50 is 
represented in database 34 to enable production of a cycle- 
accurate high performance simulation model as well as a 
5 synthesizable Verilog model. 

The graphical model 50 includes of a set of blocks 52, 
interconnected by lines 54. Each of the blocks 52 represents 
logical elements of a device under design. The lines 54 
represent connections of block inputs to block outputs. Every 
10 block in the graphical model 5 0 is an instance of a specific type 
of block. The type of block determines the relationship between 
'J3 a block's outputs and its inputs, states, and time. The 

S graphical model 50 may contain any number of instances of any 

M type of block needed to model a system. 

yi 

15 Although not illustrated in FIG. 2, each of the blocks 52 

p and lines 54 are linked to a Register Transfer Diagram (RTD) 

i 

m descriptions allowing the user 3 0 to navigate and drill down to a 

g particular place in the design quickly. This allows the user 3 0 

^ to capture the design intent and then to successively refine the 

20 design. In a RTD view (not shown) of the graphical model 5 0 

logic is color- coded. For example, state elements are shown in 
blue, semantically correct combinatorial logic is shown in green, 
common blocks describing pipe stages are shown in white, ports 
identifying inputs /outputs of the RTD are shown in yellow, and 
25 library elements with correctly matched inputs and outputs are 
shown in gray. Other schemes can also be used. 
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Each of the blocks 52 and corresponding lines 54 are stored 
in the database 34 . More specifically, the blocks and 
corresponding connections are stored in one or more data 
structures that represent the gates, nodes and nets of the 
5 device. The data structures provide an internal list or 

description of a net list of the device is stored in the database 
34 . 

Referring to FIG. 3, an exemplary data structure 60 
implemented in C++ and stored in the database 34 and representing 
10 an exemplary description of a graphic model includes M-Gate (62), 
M_Pin (64), M_Net (66) and M_node (68), where ^M 1 ' represents 
! fl Model. The data structure may be implemented, for example, as a 

*fi linked list or binary tree. 

Nj The M-Gate (62) represents a logical function, for example, 

13915 AND, FF, FIFO, and so forth. The M_Gate (62) contains zero or 
O more input pins (M_jpin's) and zero or more output pins. Each 

eg 

il distinct logical function in the graphical model 50 is assigned 

: ;) ■S? ! S 

^ its own derived M_gate type. 

The Mjpin (64) represents a connection point to a gate. The 
20 connection may be either an input or output. It connects an 
M_gate to an M__net. 

The M_node (66) represents the total extent (i.e. all bits) 
of a simulation state. 

The M_Net (68) represents an arbitrary collection of bits 
25 within an M__node. An M_net connects one or more M__pin ! s 
together. 
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M-Gate (62), M_Pin (64), M_Net (66) and M_node (68) are all 
C++ classes in which there are multiple derived classes for each 
class listed above. 

The data structure 60 is updated and reflects the current 
state of the graphical model 50. The data structure 60 is used 
by the logic modeling process 100 to generate an architectural 
model using, for example, C++ constraints, and a Verilog 
implementation model. Thus, a single database, i.e., the 
database 34, is used as generator of both an architectural and 
implementation model for a chip design. 

Referring to FIG. 4, the logic modeling process 10 0 includes 
graphically capturing (102) combinatorial blocks, state elements 
and graphical library elements. Graphics elements in the 
library may be definable or may have predefined functions. For 
example, the library may contain software objects that perform 
the function of a FF or a latch. The library may also contain 
graphics elements that are undefined, i.e., that have no code 
associated with them. 

A block in a graphical model may represent a single 
combinatorial element, such as a multiplexer or state element. A 
combinatorial block represents the functionality of several 
combinatorial elements or the function of several state elements. 

The process 100 builds (104) a control/design analysis and 
checks (106) for errors. For example, process 100 determines if 
there are any un- terminated or inconsistent connections in the 
design. If any such problems are detected, process 10 0 issues an 
error message to the logic designer. The error message may 
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specify the nature of the problem and its location within the 
logic design. The logic designer is then given the opportunity 
to correct the problem before process 100 moves forward. 

The process 100 stores (108) the logic of the graphics 
5 capture in a data structure. The process 100 determines (110) 
whether to write an architectural model or implementation model. 
If an implementation model is to be written, the process 10 0 
generates (112) Verilog using Verilog constructs to provide the 
implementation model. 
10 If an architectural model is to be written, the process 100 

_ coverts (114) the data structure into a C++ topology. The 

process provides (116) timing and clock domain assignments 

;*F partitions (118) clock domain topologies. Each partition is 

M; coded ordered (12 0) and partition code provided to a C++ 

£§15 compiler . 

□ Code ordering means that the logical constructs are sorted 

CO 

fy based on producer/consumer. BY subsequently code-ordering the 

q C++ model may be simulated as a single call model. A single call 

model means that each logical construct is evaluated only once 
20 per cycle. Hence, the C++ model simulator is a cycle-based 
simulator. The Verilog model is also written after being 
extracted from the data structure and is typically simulated 
using an event driven simulator such as ModelSim™ from Model 
Technology, for example. 
25 The process writes (122) C++ files, batch files and 

makefiles for the architectural model. Thus, process 100 
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generates high performance C++ and highly efficient Verilog from 
the same database. 

Process 100 may be implemented using one or more computer 
programs executing on programmable computers that each includes a 
5 processor, a storage medium readable by the processor (including 
volatile and non-volatile memory and/or storage elements) , at 
least one input device, and one or more output devices. 

Each such program may be implemented in a high level 
procedural or object-oriented programming language to communicate 
10 with a computer system. Also, the programs can be implemented in 
assembly or machine language. The language may be a compiled or 
y3 an interpreted language. 

«p Each computer program may be stored on a storage medium or 

U device (e.g., CD-ROM, hard disk, or magnetic diskette) that is 

I:Q15 readable by a general or special purpose programmable computer 

IS; 

Q for configuring and operating the computer when the storage 

5 

l*§j medium or device is read by the computer to perform process 100. 

S Process 10 0 may also be implemented as a computer-readable 

}W4 storage medium, configured with a computer program, where, upon 

20 execution, instructions in the computer program cause the 
computer to operate in accordance with process 50. 

Further aspects, features and advantages will become 
apparent from the following. 



7 



